1. Technical Field
The present invention is directed to an apparatus and method for inter-object communication. More specifically, the present invention provides a mechanism for tracking object references between separately installable and replaceable modules in an object oriented system.
2. Description of Related Art
Dynamic Object Oriented Languages, such as Java™ and Smalltalk™, have become common for implementing complex software systems. These languages implement the illusion of a computation module in which loosely coupled objects interact by making requests of each other. These languages typically provide an object oriented memory management system in which the resources needed to implement an object (typically storage) are explicitly allocated when required, but do not have to be explicitly freed. The run-time implementation of the language (often called the virtual machine) maintains a root set of objects and ensures that any objects which can be transitively reached from those root objects will be maintained. Objects which are no longer reachable may have their resources reclaimed for reuse. This reclamation is commonly called garbage collection.
Later implementations of virtual machines have provided for certain references between objects to be marked as weak. In finding paths from root objects during garbage collection, weak references are not counted, and so objects only reachable through paths containing weak references can be reclaimed. In other words, at least one strong reference is required to maintain an object. In Java this mechanism is implemented in the package java.lang.reference.
These languages have enabled and fostered the implementation of systems in which independently developed collections of objects can operate within the same system and interact. The objects can be brought into interaction through a variety of techniques. For example, specific code may be written to the independently developed objects together. Alternatively, a visual programming paradigm may be used to allow “power users” to assemble applications from a toolkit of objects. More recently, systems have been developed which provide frameworks for discovery of other objects based on their characteristics.
Two such frameworks that are of interest in understanding the current invention are OSGi™ and Jini™. The OSGi framework supports the interaction of independently developed collections of objects. Such collections are termed “bundles” in the OSGi architecture. OSGi bundles may be manually configured using properties. OSGi also provides discovery mechanisms for bundles based on bundles publishing one or more “service interfaces.” One of the primary goals of the OSGi framework is to allow bundles to be independently installed, started, stopped, and removed. The success in attaining this goal, however, depends on the details of how the bundles are written.
Problems arise in the OSGi architecture because a bundle which obtains services from a second bundle logically owns objects related to those services, but the objects in question are physically associated with the second bundle. If the first bundle maintains references to these objects, the second bundle will not be able to completely unload when required because the virtual machine will maintain some of its objects.
Many of the common techniques in object oriented design give rise to such references. For example, a commonly used technique called the listener pattern allows for objects to register interest in receiving events relevant to another object. One of the first implementations of the listener patters was the object dependency mechanism implemented in the Smalltalk-80 language. In the Smalltalk-80 language, any object could have a list of dependants (listeners). Because many objects did not have dependents, Smalltalk-80 objects did not in general maintain direct references to their listeners. Instead, a central registry was provided which associated a list of dependents with each object that had dependents.
This implementation conserves resources because of the sparse use of dependency. However, this implementation causes a problem in that establishing a dependency relationship causes references from a root object (the dependency registry) to both the object and each of its dependents. Unless dependency relations are explicitly broken, such objects will never be reclaimed. Later implementations used weak references in the registry. This solved the problem, but also was incompatible with applications which solely used the dependents registry to keep objects “alive.”
The OSGi framework uses the listener pattern to allow objects to receive events about the coming and going of service registrations. The OSGi architects soon realized that this causes the same kind of problems with “zombie” references as did the Smalltalk-80 dependents mechanism. Because of this, the architects introduced a new pattern called “Whiteboard” which uses OSGi service registry as a way of implementing listener registration. While this solves the immediate problem of the listener pattern, it does not solve the general problem of providing loosely coupled object references between bundles. The present invention addresses this more general problem.
The JINI™ framework provides mechanisms for Java objects to discover each other and interact over a network. The JINI framework needed to address the problems of partial hardware failures and communication channel failures. In JINI, unlike the case in the OSGi framework, the different objects are located in different physical machines and communicate over unreliable links. Failure modes include failure of a remote machine or disruption of communications. To address this problem, JINI uses a pattern called leasing. In this pattern, when an object requests a service such as listener registration, or transaction initiations from a second object, the interaction is represented by a lease object returned as a result of the request for service initiation. The lease includes an explicit time for termination, which is negotiated between the two objects. The first object requests a time interval, and the second may either agree, reduce the time interval, or decline entirely. The client may request extension of the lease prior to its termination, subject to the same negotiation over the extension period. The benefit of the leasing pattern is that if a partial failure occurs, both client and server can release any resources associated with the interaction when the lease expires, without need for further communication.
The leasing pattern, while ideally suited for distributed systems with partial failure behavior is unnecessarily complicated and undesirable in the typical OSGi framework which runs in a single hardware environment. For example, in the absence of partial hardware or communication failures, there is no need for lease renewal.
Thus, it would be beneficial to have an apparatus and method for detecting and recovering from software failures in one of a pair of communicating modules/bundles in a single hardware environment. In addition, it would be beneficial to have an apparatus and method for handling intentional stopping or removal of one or more modules/bundles by a third party, e.g., an operator interface application.